Trace 中文是 追蹤

但，在這邊可不是只是一般的追蹤而已

在這裡Trace這張資料表代表的是分散式追蹤的結果

那麼什麼是分散式追蹤呢？

這東西是由於現今我們在於雲端技術快速的演進，雖然上面的服務更容易被我們使用

但是卻造成了整體系統更難以理解和偵錯

舉個例子：現在有**三個方法(Method)**分別為A，B，C

我們可能會使用方法A去呼叫方法B，再用方法B去呼叫方法C

或是如果你高興的話，你也可以在方法A呼叫方法B，諸如此類的用法

那...我們該如何在Azure Application Insights去做偵錯呢？

這時候有個叫做分散式追蹤的好東西就出現了

分散式追蹤相當於雲端和微服務架構裡的呼叫堆疊，但增添了簡易的效能分析工具。
新增了時間維度的呼叫堆疊可顯示單一交易/要求，可以協助我們找出問題的根本原因及每個要求的效能瓶頸。

那....我們該如何操作呢？

這邊我們就要開始寫點Code了

就如前一篇Day - 12. 自訂事件和度量(customEvents)，調用TelemetryClient提供的方法

只不過這次我們要調用的是TrackTrace

使用TrackTrace可以讓我們藉由留下麵包屑來診斷問題

不清楚什麼是麵包屑的人，請點擊由此去查看或是google 糖果屋

只是這邊我們的麵包屑不會被吃掉 哈哈哈

TrackTrace需要三個參數，分別為message、properties、severityLevel

接著讓我們在TestA方法中塞入下列的程式碼

telemetryClient.TrackTrace("TestA",
                SeverityLevel.Warning,
                new Dictionary<string, string> { { "TestA", "Warning" } });

接著就讓我們將應用程式發佈到Azure上去

接著再讓我們帶上查詢

traces 
| where * has "TestA"

我們同樣的也得到了我們所需要的紀錄